Looks good to me!

I guess this is technically a backwards incompatible change so we should make a major version bump. Any code that is depending on error handling by subclassing requests.exceptions.RequestException will fail with this change as it is currently written.

Here is the test that is failing:

    def test_duplicate_folders(self):
        first_folder = self._random_filename()
        py.file_ops.mkdirs(first_folder)
        try:
            py.file_ops.mkdirs(first_folder)
        except requests.exceptions.RequestException as e:
            self.assertTrue(400 <= e.response.status_code < 500)
        else:
            self.fail('Expected this to fail!')

I like that the previous code's exception contained status_code. We can just modify the message or the __str__ of the requests.exceptions.RequestException but nothing else?

@chriddyp a couple thoughts. We have a PlotlyRequestException that is meant to take a requests.exceptions.RequestException and return the proper message (though I think it's outdated).

That means we have 3 ways to raise exceptions for requests:

1. Use a generic PlotlyError
2. Use a PlotlyRequestException
3. Just raise the requests.exceptions.RequestException

I'd vote for not requiring a user to import requests and always raising PlotlyRequestException (and yes +1 to a version bump since this is backwards incompatible).

I am still confused as to what I should do

I like that the previous code's exception contained status_code. We can just modify the message or the str of the requests.exceptions.RequestException but nothing else?

Doing this does not bump the version and I am not entirely sure how to change the message of requests.exceptions.HTTPError

I'd vote for not requiring a user to import requests and always raising PlotlyRequestException (and yes +1 to a version bump since this is backwards incompatible).

This bumps the version and I assume we're talking PlotlyRequestError, if so Im not sure how to get the status from the API in there.

this is what I have so far

                try:
                    # try get a friendly error message
                    errors = parsed_response.get('errors')
                    message = errors[-1]['message']
                except:
                    # otherwise raise a generic error
                    raise requests_exception
                else:
                    requests_exception.message = message
                    raise exceptions.PlotlyRequestError(requests_exception)

@alexandresobolevski , i was suggesting always raising the PlotlyRequestError (i believe that it sets the status code)

So, something more like:

                try:
                    # try get a friendly error message
                    errors = parsed_response.get('errors')
                    message = errors[-1]['message']
                except:
                    # otherwise raise a generic error
                    raise exceptions.PlotlyRequestError(requests_exception)
                else:
                    requests_exception.message = message
                    raise exceptions.PlotlyRequestError(requests_exception)

@chriddyp , I slacked with @alexandresobolevski a little bit on this. I'm going to hop in here unify how we do error handling. You're right that it requires a version bump to make this change, but I don't want to force users to change their error-handling code twice, that's silly.

@chriddyp ^^ here's a long-overdue Christmas miracle :p. I did a full overhaul on organizing our api calls in this repo. It's dead simple and unifies how both request creation and response validation work in both v1 and v2 code paths.

I also defer content parsing to the Response.json method in requests, which appears to by PY2/PY3 agnostic. This should greatly simplify problems with decoding/unicode schtuff. However, I'm going to let our test suite churn for now (may be a lot of brokenness).

And yep, this will be a big version bump. Again we were going to need a version bump as suggested in #640 (comment). I figured we may as well really tackle this error-handling thing if we're going to need to do a version bump anyhow.

Also, we're still only supporting 2.7.8 3.3.3 3.4.1, we should test 3.5 and 3.6 as well (Python devs are moving fast :p)

^^ 😮 holy $#!T! It passed already.

Manually test the following in Python 3:

• loading graph reference
• saving / retrieving plots with unicode

Just as a heads up, I tagged this as a WIP for now, I have a lot of tests that need adding in for the new api module I created. What I'd like to do is ensure that we have lots of tests with requests.request mocked and then just add a handful of tests that are actual integration tests. This test suite is unnecessarily slow right now, and will continue to feel slower as we test on more and more Python versions.

Wow, huge stuff! Looks great to me so far

Closing in favor of #650